DRAFT — under teacher review.

Functional vs Non-Functional Requirements — What's the Difference?

The Hamilton and Alexandra College · Year 12 · 2026

One of the most common errors in C3-1 is writing performance targets ("the app shall load in under 2 seconds") under functional requirements, or writing feature steps under non-functional requirements. These two requirement types are defined differently — and the C3-1 rubric checks both at 5–6 band.

Watch first (≈5 min)

Jelvix — side-by-side walkthrough of functional and non-functional requirements using concrete software examples. Watch for the pattern: functional = what the system does; non-functional = how well it does it.

The one-sentence rule

Type	One-sentence definition	Test question
Functional	A specific behaviour, action, or feature the system must perform	"Does the system do something specific here?"
Non-functional	A quality standard or constraint on how the system performs	"Does this set a standard for how well the system works?"

Side-by-side: same project, both types

The scenario: a school event booking app. A student is writing requirements for C3-1.

Functional requirements (what it does)

#	Requirement
F1	The system shall allow a student to search for events by date or category.
F2	The system shall send a confirmation email when a booking is made.
F3	The system shall allow an administrator to add, edit, and cancel events.
F4	The system shall display available seat counts for each event.

Each one describes a specific action — you could test it with a yes/no: either the system does it or it doesn't.

Non-functional requirements (how well it does it)

#	Requirement
NF1	The system shall load the event list in under 2 seconds on a standard school Wi-Fi connection.
NF2	The system shall be accessible to users with screen readers (WCAG 2.1 AA compliance).
NF3	The system shall be available 99.5% of the time during school hours (8am–4pm, school days).
NF4	The system shall store all user data in accordance with the Privacy Act 1988 (Cth).

Each one sets a measurable standard on how the system performs — you could test it with a metric (time, percentage, compliance standard).

The most common mistakes

Mistake 1: Performance targets under functional requirements

~~F1: The system shall load quickly.~~

"Load quickly" is a performance standard — it belongs under non-functional requirements, with a number attached (e.g., "in under 2 seconds"). Functional requirements describe actions, not speeds.

Mistake 2: Features buried under non-functional requirements

~~NF1: The system shall have a login feature.~~

A login feature is something the system does — it is a functional requirement. Non-functional requirements cannot introduce new features; they can only constrain how existing features perform.

Mistake 3: Vague non-functional requirements

~~NF1: The system shall be easy to use.~~

"Easy to use" is not measurable. A non-functional requirement must be testable. Rewrite: "A first-time user shall be able to complete a booking in under 4 minutes without assistance." Now it can be tested.

The categories of non-functional requirements

The C3-1 rubric mentions "non-functional requirements of the proposed software solution." These commonly map to:

Category	Example
Performance	Load times, response times, throughput
Usability	Learnability, error recovery, accessibility
Reliability	Uptime percentage, mean time between failures
Security/Legal	Privacy Act compliance, password requirements
Portability	Runs on mobile browsers, no installation required
Maintainability	Code must be documented for handover

You do not need to use all categories — pick the ones that are genuinely relevant to your project.

Why VCAA cares

At 5–6 band, the rubric requires you to "document the functional and non-functional requirements of the proposed software solution." This means both types must appear — and they must be correctly labelled. A submission that puts performance targets under functional requirements has mislabelled requirements, which sits below 5–6.

At 9–10, your non-functional requirements must be precise enough to be testable and tied to real constraints (legal, usability, etc.). Vague NF requirements suggest the student does not understand the distinction.